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(57) Abstract: A modular interactive 
system and method for customizing 
heaJlb education to an individual al a 
remote terminal lo induce a modification 
in a health- re la ted behavior of the 
individual. The first step is lo name 
the future program (700). Next, a user 
selects the disease libraries (710) from 
which the program dialogs are crcaied. 
Simultaneously, the user checks the 
Utilities Library (720) lo add dialogs to 
the program that' are not disease specific 
like generic greetings. . Creating the 
program is now a simple task of adding 
dialogs to the program list (730), arid to 
define Ihe delivery of the dialogs (740) as 
a user can choose specific delivery of the 
dialogs on a daily (750). weekly (752), or 
any other (754) programmed timed bases. 
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AN INTERACTIVE PATIENT COMMUNICATION DEVELOPMENT. 
SYSTEM FOR REPORTING ON PATIENT HEALTHCARE MANAGEMENT 



FIELD OF THE INVENTION 
The present invention relates generally to a modular interactive 
15 development system and method for reporting on patient management, and in 
particular to an automated content delivery program able to connect remote users 
across independent platforms to a central database of libraries whereby a patient's 
health can be scored dynamically. 

20 BACKGROUND OF THE INVENTION 

This invention relates to the field of health management", particularly to an 
automated interactive system and method for reducing the risk associated with a 
monitored client. 

For example, the know art includes a number of health-management 
25 systems for providing outpatient services to patients with chronic health 
conditions such as asthma and diabetes. However, these systems are incapable of 
administering a treatment protocol responsive to the patient's current profile and 
of updating the profile in response to the administered protocol. 
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SUMMARY OF THE INVENTION 
This invention presents a flexible and scalable system in content 
development for patient management healthcare. Due to the modular object 
oriented^slructure, individual content modules ("dialogs") can be mixed into an 
5 unlimited number of updateable customized programs, addressing individual as 

« 

well, as co-existing disease states ("co-morbid") in any combinations, and with 
automated content variation for improved patient compliance. A dialog is the 
smallest content object in the FlexCube content structure. Its content addresses 
issues related to a unique set of symptoms, behaviors or knowledge related to a 
10 specific aspect of managing a certain disease referred to as an aspect of care. 

In its basic format, each dialog contains questions related to signs and 
symptoms, behaviors and knowledge with answers categorized as high, medium or 
low risk answers. For each answer there is a relevant follow up, which can be a 
teaching statement, an acknowledgment, a motivational statement or a new 
question that will explore the patienfs condition in more depth. While the logical 
branching within a dialog is driven by patient answers, no dependency exists 
between individual dialogs. 

Dialogs are located in a common pool organized by library. From this 
library each individual dialog is referenced for participation (appearance) in 
programs and daily sessions. A dialog's behavior in a program (schedule, position, 
reporting) is defined at the time of the dialog creation or it is custom defined 
during the program content selection process. In this way dialogs maintain their 
.integrity while being used and re-used in several client programs. They combine 
freely with other dialogs in user defined program selections, allowing an unlimited 
combination of aspects of care and co-existing diseases. Finally, they are easily 
accessible for revisions and updates. 

* 

The present invention provides an object-oriented dialog and modular 
toolkit structure that enhances quality control options. Also included are the 
centrally located content objects that offer overview and tracking of the currently 
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active content, global eiror correction and global update of content to current 
standards of care. Because the present invention, splits up interfaces for content 
creation and content selection into separate modules, the present invention 
exercises control over customer's access to content development in compliance 
with current and future Federal Drug Administration labeling. Finally the system's 
structure limits logical branching errors to within a dialog, thereby offering a more 
robust and less error prone system overall. 

Since the content of a dialog and the output of a dialog is related and 
mapped to a specific aspect of care, the user will have the power and flexibility to 
10 model risk evaluation and outcomes reporting around custom selected aspects of 



care. 



BRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing aspects and many of the attendant advantages of this 
15 invention will become more readily appreciated as the same becomes belter 
understood by reference to the following detailed description, when taken in 
conjunction with the accompanying drawings, wherein: 

FIGURE 1 is a block diagram depicting a system's compositional and 
referenced components; 

20 FIGURE 2 is a flow chart diagram depicting the overview of dialog 

creation; 

FIGURE 3 is a block diagram depicting an interdependent characteristics 
(operators) of a dialog; 

FIGURE 4 is flow chart depicting the steps in creating and storing of 
25 content data from a dialog; 

FIGURE 5 is a flow chart diagram depicting the creation of the 
programming statements using a Dialog Editor Platform; 

FIGURE 6 is a block diagram illustrating the three dimensional aspects of 
the dynamically determined risk state output scale; 
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FIGURE 7 is a flowchart depicting the creation of programs using a 
Program Composer User Interface; 

FIGURE 8 is a flow chart depicting a Linker User Interface; and 
FIGURE 9 is a flow chart depicting a Reporter User Interface. 

5 

» - 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT 
The present invention includes an object-oriented content structure in 
which the smallest content object, a care specific dialog, is located in a central 
library from where its characteristics (operators) are composed and referenced by a 
10 modular set of tools located at a client computer. 

FIGURE 1 is a block diagram depicting a system 1 0's compositional and 
referenced components. Compositionally, the system 10 relies on four system 
components for dialog or program creation. Additionally, FIGURE I illustrates 
two other system components that interact with the referenced components of the 
15 system. A dialog Composer 20, further referenced in FIGURE 2, which is used to 
author dialog content by an aspect of care. A Program Composer 30^ further 
referenced in FIGURE 7, is a user interfaced click and drag assembly platform for 
composing programs (a virtual content defined collection of dialogs). On a 
computer desktop, content dialogs are selected (referenced) for use in 
20 disease/client specific programs, with program specific tagging of individual 
dialog attributes related to frequency (scheduling) and reporting. A Program 
Patient Linker 40 is a user interface integrated into the desktop on which patients 
are assigned to programs. During Ihe assignment process patient identification and 
patient specific metrics are added to Ihe program. A Care Reporter 50, further 
25 referenced in FIGURE 9, is a user interface for easy patient result lookup, triage 
and trend reports. Reporting requirements set in Ihe Program Composer 30 
determine which reports are displayed. 

Compositional elements of the system 10 reference either one or both of 
ihe two remaining components of Ihe system depicted in FIGURE I . A Program 
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Scheduler 60, further referenced in FIGURE 8, is an engine for automated 
scheduling of dialogs based on attributes set in the Program Composer 30, and A 
Dialog Library 70. The Dialog Library is the principal central location of dialog 
content units. Dialogs are organized into body system labeled sub-libraries and 

stored within the Dialog Library 70. 

■ ■ • V 

The structure of the system is developed from the integration of the four 
compositional components as referenced above with the two referenced 
components and begins with the creation of dialogs in the Dialog Composer 20 as 
depicted FIGURE 2. 

FIGURE 2 is a flow chart diagram depicting the overview of dialog 
creation and is referenced with more particularity in FIGURE 4. Referring to 
FIGURE 2, a patient 100 reports on a specific aspect of care 1 10 (i.e., foot care in 
a Diabetes Structure) that is addressed by a dialog 125, the smallest content 

* 

structure of the system, from a disease specific library 120. The basic format of 
each dialog includes questions 130 related to patient self-management behaviors 
132, patient-reportable symptoms 134, or patient knowledge 136. Each question 
provides a choice for an answer ("output variable") 140 that falls into one of three 
risk categories; high 142 medium 144 and low risk 146. For each risk category 
there is an associated follow up 150 which is a teaching statement 152, a 
motivational statement 154 or a new question 156 that explores the patient's 
condition in more depth. ~ 

While die logical branching within a dialog depends on output variables, 
no dependency exists between individual dialogs. Dependencies for dialogs exist 

outside the dialog structure in related operators. 

rt- . . . ■ • . - 

FIGURE 3 is a block diagram depicting the interdependent characteristics 
(operators) of a dialog 300 in the system matrix. The interdependent 
characteristics include a Name Label 310 for the aspect of care addressed, a 
Library 320 that houses a body system specific Localization 325, client specific 
Programs 330 in which the dialog is being used (referenced), a Schedule frequency 
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340 by which the dialog is being displayed to a patient in a specific program, 
definition of Reporting requirements 3.50, and Patient Identification information 
360 and metrics of each individual appliance to which the dialog is assigned. 

The user interface is easy to use due to the simplicity of program structure 
in which the user is able to interface with the program and dialog composition 

■ • 

aspects of the system. Simply using drag and drop content selection procedures 
based on a medical decision creates a process familiar to the user. The user 
decides what aspects of care are relevant for a given program or for an individual 
patient and in most cases simply selects existing content based on that decision. In 
all steps of dialog composition, certain steps are talcen to make available the dialog 
in a content library. 

FIGURE 4 is a flow chart depicting the steps in creating and storing of 
content data from a dialog, a user's first task is to name the dialog-to-be created as 
depicted in block 400. Next, the user defines the library section of block 410 in 
15 which the dialog will reside. The user then identifies an aspect of care at block 420 
to which the dialog will primarily refer. Once the naming conventions are assigned 
and the aspect of care is chosen, the user creates dialog programming statements at 
block 430, in a graphical programming environment as embodied in FIGURE 5. 
New dialog content is then stored in an appropriate user library at block 440. 

9 

20 The user who has access to create new content does se using a simple 

dialog composer as embodied in FIGURE 5. FIGURE 5 is a diagram depicting the 
creation components of a dialog Editor Platform. First, a user is presented with a 
palette 500 of programming statements that are represented as graphic symbols 
(icons) that can be dragged from the palette of available statements into a dialog 

25 construction platform 505. In a typical embodiment of the present invention, the 
user drags a start question icon 510 and a three pronged answer icon 520 from an 
icon palette down to the construction platform 500. The user then activates a 
dialog box for each icon by clicking on it with a mouse and specifying a question 
associated with lhal particular icon, for example, a Start Question Dialog 515. 
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Next, in an Answer Dialog 524, the user enters three answer options relative to the 
start question and assigns a raw risk value to each answer 526. The risk values are 
assigned from high to low with a corresponding text answer. "Yes" equals low 
risk and "no" equals high risk and "medium" equals somewhere in the middle of 
5 low and high risk. Follow up questions icons 530 are dragged onto the 
construction platform along with an associated answer icon 540. An answer dialog 
545 is then prepared. Clicking on the output icon 550, the user activates the output 
dialog box 555. Here the user defines risk state output 558 in detail, further 

m " * * * * 

depicted with more particularity in FIGURE 5, defining the position of the answer 

* ■ 

10 relative to the axis of the risk cube. At any time during or aller the dialog creation 
process, the user can review the dialog created, using a simulation interface to an 
appropriate appliance or in the alternative, the user can review the actual dialog 
content in a text only overview window. Once all the follow up questions, answers 
and output dialogs are formulated and put onto the construction platform 525, the 
15 newly created dialogs are store in a user library 560 from where it can be 
referenced for participation in any user defined care management program or for 
later updating or editing. 

FIGURE 6 is a block diagram illustrating the three dimensional aspects of 
the dynamically determined risk state output scale which in the Dialog Composer, 
20 FIGURE 5, is referenced at block 558. The X-axis 610 scales whether the answer 
to a question dialog sets the risk at a certain risk level on a 9 point risk scale or 
whether the answer moves the patient risk state in a certain direction and by how 
much, thereby creating an accumulated risk profile. Additionally, the answer to a 
dialog is incorporated as a value in a mathematically calculated risk slate that may 
5 incorporate other answers as well, creating a composite, weighted risk state. The 
Y-axis 620 refers to Ihe actual aspect of care in which the risk will be 
incorporated. The 2- axis 630 incorporates the expression of risk 530, i.e, whether 
the risk is assigned to a sign or symptom 632, a behavior 634, or a knowledge 
expression 636. This dynamic model allows for very sophisticated risk profiling 
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including risk trend alerts, composite risk profiling by aspects of care and profi ling 
by risk expression. The dynamic risk "foot prints" available at any time can serve 
as triggers for automated content selection. 

Once dialogs are named, created and assigned to an aspect of care and the 
5 risk output is assigned to the appropriate dialog, a user of the system can then use 
the Program Composer 30 to create the program that eventually is assigned to a 
patient. 

FIGURE 7 is a flowchart depicting the creation of "programs" using the 
Program Composer User Interface fW). The UI is a platform for selecting 
1 0 library resident Dialogs created as depicted in FIGURE 6, for participation in user- 
defined care management programs. In a typical embodiment of the present 
invention, the first step is to name the future program block 700. Next, at block 
710, a user selects the disease libraries from which the program dialogs are 
created. Simultaneously, at block 720, the user checks the Utilities Library to add 
15 dialogs to the program that are not disease specific like generic greetings. This 
gives the user access to the detailed content of both of these libraries organized by 
aspects of care and their respective dialogs. Creating the program is now a simple 
task of adding dialogs to the program list, see block 730, and at block 740 to 
define the delivery of the dialogs as a user can choose specific delivery of the 
20 dialogs on a daily 750, weekly 752, or any other 754 programmed timed basis. 
Additionally, at block 742, a user checks the priority of dialogs, to set parameters 
necessary for the correct scheduling of the dialogs in the program. Options are to 
force the scheduler to include the dialog block 744, or to assign dialogs as fillers, 
block 746. The later could be the case, for example, with trivia type dialogs, 
25 entertainment dialogs etc. Also, the user has the opportunity to decide the 
placement of dialogs in daily sessions. Greetings, for example, should be checked 
as "always first." The user can review the complete created program using the 
""View Selection" link, block 760. Using a very simple interface, the user has now 
created a -totally custom made program. At block 770, the program is now 
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available for assignment to any of the user's patients or for later modification by 
the user by adding or deleting dialogs. The present invention embodies the 
assignment by way of a Linker User Interface ("Linker UT) as depicted - in 
FIGURE 8. . . 

FIGURE 8 is a flow chart depicting the Linker Ul, which is a platform for 
assigning or 'linking" care management programs to patient populations or to. 
individual patients. The first step at block 800 is to retrieve patient's name(s) to be 
used on the work platform through a filtering or sorting procedure defined by the 
user. Next, at block 810, the user marks the patient(s) arid the care management 
program to be assigned. Finally the user creates the 'link" to activate a dialog 
box that allows the user to specify a time frame in which the program will run for 

* • 

the selected patient(s), block 820. Should the user wish to link the patient to other 
programs all that is needed is to repeat the process. To process the linking of an 
entire population or part of a population a user selects ajl patients, block 800; and 
assigns all of them, block 810, to a program. . 

The last step in the creation of a system program is the creation of a 

Reporter User Interface ("Reporter Ul") which creates patient reports specific to 

■ 

patient results that in him can initiate program actions based on those results. 
FIGURE 9 is a flow chart depicting the Reporter Ul and the creation of reports. 
The layout of the Reporter Ul is completely consistent with that of the Linker Ul 
depicted in FIGURE 8. First a user retrieves patient names through a filtering 
process, block 902. The user filters, at block 900, names through the programs by 
either risk search, block 904, the aspects of care, block 905, within each program, 
or the risk expression, block 906, as defined as a symptom, behavior or 
knowledge, block 908, factor. This is done to allow a user to trend a risk profile, 
block 910, for the patient in the aspect of care where the patient has scored, for . 
example, a high-risk profile as depicted in FIGURE 6. A user can configure the 
Reporter Ul to display block 920 the actual answers or results that led to the 
exampled high-risk profile. Lastly, at block 930, a patient is assigned to a program 
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based on the risk profile or Aspect of Care. Reports assigned to patients can now 
for example, allow the user to see details for each aspect of care, order a report 
printed or write a note that will be associated with a linked event; 

- * 

While this invention has been described in teims of several preferred 
embodiments, there are alterations, permutations; and equivalents that fall within 
the scope of this invention. It . is therefore intended that the following appended 
claims be interpreted as including all such alterations, permutations, and 
equivalents as fall within the true spirit and scope of the present invention. 
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CLAIMS 



What is claimed is: 



5 !. A system for coding and updating a patient profile and for 

providing customized health information to an individual, said system comprising: 



a server; 



a remote interface for entering in said server questions to be answered by 
said individual; and 

a remotely programmable apparatus for interacting with said individual, 
said remotely programmable apparatus being in communication with said server 
via a communication network; 

wherein said server comprises: 

a questionnaire generator for generating a questionnaire comprising 
questmns for determining at least one of a physical condition of said individual a 
mental condition of said individual, and a behavior of said individual, and for 
transmitting said questionnaire from said server to said remotely programmable 
apparatus; 

a data gatherer connected to said questionnaire generator for receiving 
from said remotely programmable apparatus said individual's physical condition 
into a physical condition profile, said individual mental condition into a mental 
condition profile, said individual's behavior into a behavioral profile for said 
individual according to responses to the questionnaire; 

a script generator connected to said data gatherer for generating a 
customized script program from questions based on said individual's physical, 
mental, and behavioral profiles, and fpr transmitting said customized script 
program to said remotely programmable apparatus; 

a report generator for generating a report comprising said individual's 
Physical, mental, and behavioral profiles and said assigned customized script 
30 program; and 

♦ - 1 w 

a database connected to said questionnaire generator, said data gatherer, 
and said scrip, generator for storing said questionnaire, said profiles, and said 
script program; 

a-nd wherein said remotely programmable apparatus comprises: 
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a communication means for receiving said questionnaire and said script 
program from said server and for transmitting said responses to said server, 

a user interface for communicating said questionnaire and said script 
program to said individual and for receiving said responses; 

5 a memory for storing said questionnaire, said script program, , and said 

. responses; and 

* 

a processor connected to said communication means, said user interface 
and said memory for executing said questionnaire and said script program to 
communicate said questions to said individual, to. ^receive said responses to said 
10 questions, and to transmit said responses to said server. 

2. The system of Claim 1 , wherein after said responses are transmitted 
to said server, additional physical, mental, and behavioral profiles are created and 
an additional script program is created. 



15 



3. The system of Claim 1, wherein said questionnaire generator 
further comprises a registration means for registering a name of said individuaJ, a 
language of said individual, and a current health condition of said individual; and 
said questionnaire generator and said script generator comprise a tailoring means 

20 for tailoring said questionnaire and said script program in dependence upon said 
language and said current health condition of said individual 

♦ * 

4. The system of Claim 1, wherein said questionnaire generator 
further includes a confirmation means for confirming with said individual said 

25 physical profile, mental profile, and behavioral profile. 

■ 

5. The system of Claim 1, wherein said $cript program comprises: 
a request for clinical data; 

a moniloring question; and 
30 educational informal iori. 

- 

6. The system of Claim 5, wherein said educational information 

composes means for accessing an external source of additional educational 

■ 
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information and means for transferring said additional educational information 
from said externa! source to said remotely programmable apparatus. 

7. The system of Claim 1, wherein said data relating to said physical 
condition of said individual comprise measurements which are received from a 
5 monitoring device connected to said remotely programmable apparatus. 

... ■ 

- 8. The system of Claim J, wherein said data relating to said physical 
condition of said individual comprises medical claims received from a managed 
care organization of said individual; 

10 

9. The system of Claim 1, wherein said data related lo said physical 
condition of said individual comprises electronic medical records received from a 
health-care provider of said individual. 

» 

■ • 

15 ,0 - A method for providing customized health information to an 

individual to induce a modification in a health-related behavior of said individual, 
said method comprising: 

exchanging data with a server through a communication network, wherein 
said data includes a questionnaire and a script program executable by said 
20 remotely programmable apparanis to communicate questions lo said individual, to 
receive responses to said questions, and to transmit said responses to said server; 

storing said questionnaire, said script program, and said responses to said 
questions; 

communicating said questions to said individual and~for receiving said 
25 responses to said questions; and 

executing said questionnaire and said script program; 
transferring from said server to said remotely programmable apparatus said 
questionnaire containing quesl ions for determining a physical condition, a menial 
condition, and behavior of said individual; 
30 receiving in said server responses lo said questions entered by said 

individual from said remotely programmable apparatus; 

generating from said responses a physical condition, a mental condition, 
and a behavior of said individual; 



13 



VVO 01/69505 vcrmomuu 



translating said physical condition, mental condition, and behavior into 
physical, mental, and behavioral profiles of said individual; 

generating a customized script program for said individual based on said 
physical, mental, and behaviorai profiles; and 

script program to said remotely programmable 

apparatus. 

■ 

■ 

* » 

11- The method of Cfaim 10, further comprising creating additional 
physical, mental, and behavioral profiles and an additional scrip! program after 
10 said server receives said responses. 

12. The method of Claim 10, further comprising registering a name of 
said individual, a language of said individual, and said current health condition of 
said individual in said server prior to transferring said questionnaire; and tailoring 

15 said questionnaire and said script program to said individual in dependence upon 
said language and said current health condition of said individual. 

■ 

13. The method of Claim 1 0, wherein said script program comprises: 
a request for clinical data; 

20 a monitoring question; and 

educational information. 

14. The method of Claim 13, wherein said educational information 
comprises means for accessing an external source of additional educational 

25 information and means for transferring said additional educational information 
from said external source to said remotely programmable apparatus. 

15. The method of Claim 10,. further comprising generating a report 
comprising said individual's physical, mental, and behavioral profiles and said 

30 assigned customized script program. 

■ 

16. The method of Claim 10, wherein said data relating to said physical 
condition comprises measurements which are received by said server from a 
momtoring-device connected to said remotely programmable apparatus. 

14 
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17. The method of Claim 10, wherein said data relating to said physical 
condition of said individual comprises medical claims received from a managed 
care organization of said individual. 

18. The method of Claim 10, wherein said data relating to said physical 
condition of said individual comprises electronic medical records received from a 
health-care provider of said individual. 

> 

19. A clinician computer system, the clinician system in 
communicating with one or more patient device, the clinician system comprising: 

a database comprising questions, answer and follow-up act ions- 
a display; 

a processor; and 

a graphical user interface executed by the processor and presented on the 

display comprising: 

• * 

a selection component for selecting a question, answer or follow-up action 
from the database; 

an icon generator for generating and displaying an icon associated with the 
20 selected question, answer or follow-up action; 

a linking component for linking displayed icon; and 

a conversion component for converting linked displayed icons into a scrip 
program; 

a sending component for sending me script program to a patient device 
25 over a communication network. 
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Executive Summary 

Introduction 

""estimation of tiLys^S 

FlexCube. * 566,1,6 SeCbODOn S ^S B for more defied information about 

system would differ in several respects TteL,^ ™J . " for 9,1 nationality. A production 
based application. Minor adj ™ uW ™ « a |hin-cl£m WdT 
for initia. testing wil, „ 0 , be scalable^^^ »• used . 

relatively easy to migrate to a fid. produc JdSS^ ■ ^ **? be 

development and hopcmlly ly EESEfiSlKtt "m? ^ ^ °' ~ 
improve content development and patient fare wWle^Li™^ h E ' " f ° f ' h,S SyS,era '» radically 
given population ~ WlU ' e ,educm e ,he human ICS0U T C « necessary to manage a 

Implementation 

S£K BS^JS^Er^.^ compu,a - A cabk 

to distribute content t0 remote ^SSffl" 10 . 1 ? 1 The Prototype w ill oniy bc ab , e 

Difficulties are expected in manner . *W^ mto ™™ s «-stmg data-center iniastructme, 

thev .« based on ^TnTSS*^ te ^ — 

FlexCube sessions into IradiLnal s^v^T,„ T' T * ° U ' d be strai E»«for W ard to convert 

^ionwolbeexp.ore^ This 

to allow larger scale (Li.. * ^e. An0U,CT ° P " 0n is '° buM a ^-patient server 

^^^^'fj^L^^ f * '7 lm «* He *C»be system. Cube and 
and enhanced scripting bKL?£ hf,?',™ 65 ? requi ' e " Heal,,, Bndd y ^ase (BOB) 

as both remote ZdlZZ Z^ ^ ' ' A be ,eVera s cd to ac « 

BDB, betweeo the drta-X JSS^SfiT "* " ^ »* **** * 

Care will be taken ? t* 5 "W^J*" 5 "* f or prototype development 

system. non-standard database and GUI techniques, easing Ration to alarger 

» * 

Wmdo^GW deS" Arotato^n 0 ^ ^^/""'^B » an Application Server Schema, 
design should allowa^mt A PP««n^Applieaiio n J^mnanette- UtefinaJ- 
manager in an W gamzaf on S W a hmTT "I ^ ^ " Us ° ** care 
and results for ag'grega.e « ~Un g * P CaU ° n ^ Se P" a,c ^ server could track content 

* ♦ • 

iffSitejKl^^^ ^cmresandBDBs wdl be deve.oped 
.o support the cube acd » wiU *- features 

The MBV OemoBox Compost application „iU he leveraged i„,o a dialog editor for the FlexCube system. 
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Resource Utilization 

Erik Jensen (Creator of theRexCube concept) - Will provide overall manaeement. direction in ,K„ 
roncuonal and user-interaction portions of the system. ^ ' " " Ap 

Daniel Lindsey - Will provide engineering direction and gnidance throughout the production of the 
prototype system. Work with Albert Bodenhamer to design databases. proauctoon of the. 

Albert Bodenhamer - Will be responsible for implementing Windows GUI and database portions of the 
Adam Wozniak - Will be responsible for implementing me enhanced scripting language Wd support - 
S^Ste? bCI ' Sp0n?ib,e ^'™P^ntr D g3DBs, VMBpport; appBa^HeT^emrainr "■ 
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System Components 

• Health Buddy Database (BDB)- A micro database object that moves cube content, dialogs, and raw 
response information [o and from tbe appliance via XML 

XML Schema Objects - For transporting Patient Cubes, Dialogs v Box Control Info, etc. 
Application Server Schema Stores patient data, patient demographics, personalized program/dialog 
content, paiient cube-state, and raw response data 

Applications 

Appliance 

• Box Manager Application - High level control over appliapce functionality, implements to-do list 

• Session Manager - Manages To Do list, launches content applications 

• FlexCube Presenter App - Provides sessions by executing dialogs and updating cube state 

• User Login Manager - Enables patient login and authentication 

• CommunJcatlons Manager - Overall responsibility for non-conversational commumcalions 

• Connection Manager -Brings up physical correction 

• Login Manager -Responsible for logging into bost system 

• Moil Exchange Manager - Responsible for data exchange between appliance and bost 

Windows GUI 

• Administrator Application - Provides system maintenance and data entry features, account setup 
patient entry, etc. 

Dialog Editor / Composer - Enables the creation and maintenance of non-personalized dialogs within 
libraries, dialog labeling, and importfexport capaburty to the application server database 
Program Selector - Selects dialogs from libraries in and out of content specific programs, specifies 
labels for scheduling aod reporting . 

Personalizer - Maintains patient- specific cube metrics, defining risk levels, etc. 



6 of 30 



WO 01/69505 PCIY1JS0J/086J4 

* Session Scheduler - Semi-automatic creation and scheduling of patient specific sessions 

* Reporter- Patient results lookup organized into levels from patient- specific program overview to raw 
results from particular session, including graphical body system view. 

Future Additions 

• Enhanced Scripting Language - Enables the appliance to manipulate BDBs, supporting raw data 
collection and cube /dialog interaction • 

* Appliance Apps - Script Language implementation of appliance applications. 

• Thin-CIlent Reporter - Allows system access via the Web 

• Global Patient List Server - This server maintains a list of all patients that HHN has serviced As 
new patients are added, they will be assigned a Globally Unique ID, which will follow them around 
our service. 
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Implementation Strategy 

Milestone 1 - Build Foundation and Design System 

Initially, construction will begin on foundation objects 2nd code while desien decern.* ,„ k~ e i- , 
for fte system architecture; Foundation work includes BOB tn&u^SS^Z^ ^ 

• * ■ 

• JRough-draft GUI design 

• Project Schedule 

• Scripting Language Selected 

• Architectural decisions finalized 

• Rough-draft application server schema 

• BDB library code, suitable for integration onto appliance and Windows 

• Enhanced Scripting environment with HAL support 

• Dialog Editor with branching, calculation nodes, decision nodes, etc 

Milestone 2 - Present a Session on the Appliance 

W^'^ 2 ' aPP,,a0Ce Wi " b£ Cap8bIe ° f downlMdin « a ^ioo generated by the Windows a DDS 
and present the session to a patient. J maows apps 

• Finalized Schema 
Finalized GUI design 

• Windows apps scheduling content into sessions 

• Windows apps generating output XML 

• Appliance reading content XML into internal format 

• Presenter application on appliance able to read BDB and present a session 

Milestone 3 - Round-Trip between Server and Appliance 

*S££ S rS7es , u,t ab,C '° g£nCra,e ^ *" ' bem ° n iPP,UnCe - *** *> 

• Windows apps sending scheduled session content and receiving results over the serial cable 
Appliance presenting the session and recording results 

• Windows apps uploading results from appliance and displaying raw response and cube data 

Milestone 4 - System fully Alpha 

lifS fi^fi 4 ' f W" 3 ?" «* PO" 5b «» ™* dependable through the serial Bit. The Windows apps . 
Z.^.??, ,nC ' Ude 3,1 eSSCn,iaJ -^tionality to make the system work. Wizards will have 

been added to support appiopnate system functions, especially for content composition 

• Windows apps generating reports and displaying patient status 

• Wizard funcuonality in Composer and key parts of Reporter 
•. Appliance ready to demo 
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Strategic Requirements 

Database Highly Scalable 

.We ultimately need to support 10's of thousands of users and Millions of appliances. 

Portable Content and Results 

Other appliances and systems should be capable of presenting and processing our content 

Secure and Reliable 

The system must provide controlled access to patient data, system functionality, and maintain secure' 
communications 

Automatic Generation of Adaptive Content 

The system should focus content where each individual patient requires the most attention. This needs to 
happen automatically so that we can support very large patient populations with a small group of Care 
Managers. 

Multiple Patients per Appliance 

This will open up the possibility of installing appliances at centralized locations, such as pharmacies. This 
will also.cnable families to share an appliance within a home. 

Multiple Content Senders 

Each patient using a Health Buddy needs the ability to subscribe to multiple content providers. For • 
example, a patient from Kaiser might subscribe to a diabetes program, a weightloss program, and a health 
newsletter from anoober organization. 

Multi-Lingual Parallel Content 

The system must support the large number of non-English speakers throughout the US. This feature creates 
J the potential for a global marketplace. 

Independent Appliance Decisions based on Patient Data 

Immediate Patient JFeed-Back 
Ability to Score SF36 on Appliance 

• * 

Ad Hoc patient communication 

Care providers need to be able to send personal messages and queries outside of a patient's normal" 
programs. 

Appealing Graphical Ul 

The Graphical User Interface must be pleasant for the care providers who will be using oiir system for 
hours at a time. 

Interface to Patient List Server 

This system needs to communicate with a centralized server that issues Globally Unique Patient Ids. This 
will facilitate knowing that John Smith at Kaiser is the same John Smith at Stanford's Clinical Research 
Program, etc. 
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Reports Summarized by Hierarchy Structure 

This TvUl.cnablc the system to mesh with future Information Systems. 
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System Components 

Application Server Schema/Database 

The Application Senrer Schema is the heart of the FlexCube system. An Am n • 

database. Content development genera.., cccnrsoff^ota ^ 

and exported between the installation and the actoal dau center. Iniu^fe £ t VS ? "' 

pane DIS and revicwing rcsult , „ the ^ ^ ^ ^ JSggJ ^ 

Requirements 

, ?ast Cube slate retrieval for an arbitrary date/time stamp enabling reports to be generated quickly 

• Accounts are always responsible for their o wrf programs * W qU,ddy 

• Ability to Import and Export content between Application Servers- 

: 

• Support the following Objects 

• Account Entity /Hierarchy -Support arbitrary account hier arc by 

• Group- Allow Care Managers to arbitrarily group their patients 

• Patient Notes 

• Patient . 

• Patient Demographics 

• Medications 

• Escalations 

• Patient Cube States 

• Program 

• Dialogs 

• Raw Response Data 

• Program Session Schedules 

Components /Schema Objects 

• System Table -Include Server GUID 
. Account Entity / Hierarchy 

• Group 

° Patient 

• Demographics ' ~ 

• Acct Entity Notes 

• Medications 

• Escalations 
•■ Program 

• Patient Cube -One Cube per Patient or Multiples for each program? 

• Dialog . v & 

• Response Data 
•. Session 
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Sample Application Server Hierarchy 
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X 
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Account Entity / Hierarchy 

HHN's sale, stroc J a J he ACC0UDt - ^ ^potion * reserved for 
scions will KkCy be ^^SE^^ e J^ aCC0,tt r* 68 " Much of st ™««~ « both 
-o produce ^-^g^™££££ °~ * * * 

allow HHN's real sales structure to be modeled. m S C ^ C ° tt ° m s portion. Filler entries 

^^^^^^^. Ke ^ a ^ ****** 

account within theTystel * aCCOum entnes - ^ en,rics "^lisb the root of each 

• ■ • - • » 

be created and riaced *"° W J"*™ 10 be assi ^ d «<».«*« ^es. RUer entries can 
Some accounts may wW s « ™" ^"d^ users to model the account's acmal structure. 

others may simply wT^Ton T, L +7°°' ^ t^™' ^ ~* wh " c 

an accounL ° D ' "' aaa Pat,en,i Tbe sim P les « foan is to enter all users directly under 

ccess to the system. Some entnes. such as location, may not even be allowed to 
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log in. as they only establish a reporting framework. Access to various application, and f™r,,r~ „-»k- v 
system will be set on an enuy by en., basis. Some C, Managers may ££S £ ^™ *» «* 

Ptogratiis are lied to these hierarchy entries. Programs that are tied to a user (Doctor or Care M* mo ,* 

su p C ° „ WbMeaS ' pro8ramS W 10 M account 216 considcred SSSo 

Implementation Notes 

Scaling ... 

Several tactics have been employed to support len'sof thousands of users and millions of anol.Wp, a 
account mustfit on a single Appircation Server. However, utilizing SuperNova. an "J" 
Application Servers may be established to sprtad the load. ™uary number, of 

■ ■ 

By configuring the Sin^^ 

server . Aggregation reports, combining data from multiple accounts, can be generated in pK 
combnung data from many servers while the individual Application Servers continue to run. suppwtinE 
users and appliances. ypvtuug 

• - 

Normally, an account database can not be split across multiple servers. However, the possibility of 
spreading the .load is possible by utilizing replication technology. Orable is one of mar,y databas "systems 
w,th aulomauerepheauon services. This permits multiple Care Managers and Doctors within 
orgajuzanon to each operate oo a local database and stay in sync with the centralized organization server 
Again thts provides a way to scale servers and ultimately grow the system to very large sizes ThisTs 
probably not low hangmg fruit. The atnoun. of effort necessary to implement this setup is not* know at this 
hme. However, this problem has already been solved in other systems. 

The depth of die content hierarchy has been kept as shallow as possible to remove the likelihood of 
recursive queries, Wherever possible, the schema has been designed so that all related elements can be 
grabbed in one query and assembled or sorted within the client . 

Efficient Hierarchy /Database Interaction 

Rather than implement tecarave SQL queries to grab and build hierarchies. Use the account index to grab 
aU entities wnb one query. The HHN hierarchy can also be retrieved using the same method. If necessW 
dou. can be retrieved in a single query by combining (acctS eq searchacclU) or (acctil eq rORPHHN'). " 

- Cube Stale Retrieval 

Th?iT? 3 J atit " 1 ' 5 CubcSWe f ° r 1 Poiat in time will occur very often during system processing 
The most efficient means we've found of retrieving a cube uses the following mechanism: 

1 . Cube Metrics or Values are stored in a table indexed by Cube ID, AoC, Expression, DateE freeing 
I. An additional field is added to this table called Replaced Date. 

3. A Database trigger is responsible for updating the Replaced Dote field whenever a new record is 
mserted. This places the update in the most efficient place, saving wire-time, SQL parsia- etc 

4. This enables a single query to grab the entire cube for a give* patient at a given lime as well as the 
current state by using the following queries: '* ' 

select * from metric where paient_id=our_patient and 
create_date<searcb_date and (isnull <replace_date) or 
replace_date<search_datel ; 

Content Exchange 

App Server #'s must be globally unique 
Account's 

GlobaUy Unique Object ID's 

Combining Account/? + CM ID, etc in BDBs allowing diff Recnums in different scbemas , 
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Data Aggregation 
Patient GUIDs 

■ 

Using Database Replication to spread load within Tin organization'." 
Program Security 

The security model in HexCube is tied to Account Entities. Account Entitle ™;n k j « • ' • 

access to critical system objects and applications on a per user b^L Wyt R Sm °' ***** 
able to access data across accoums. E^uon will be'used to be 

Status Group 

Slatus groups are a standard mechanism for tracking the status of patients acc 0 .,„r «,nv 

schema. The STATUS_HJSTORY table kee^s track of all ^S^SSSSS^ "» 

Features: . 

• Current Status Is this an active patient? 

Status History, ailovying the system to know what an obreci's status wa< ar w - . V 

Efficient syrrchrowzation of objects between Application Servers ^ 

Whenever a status change event occurs, the following database changes are trigge.ed- 

• The Current Status is copied into the Previous Status De 

• The Current Status is changed to the new status code 

• . The Transaction date is updated 

• A new System Transaction 3 is assigned and filled in 

• The System Dateffime h put into the Pate Effective field 

• The Database record is updated in the database 



Thoughts 

' SZSr*"* ACC0U ° t# UWe -» lEVe ' a ^ ° ff te ^count entity table. simp u fyi B6 our overa ,. 



account hierarcy. includes support for 



• Account Entity - Maintains 

• Patient 

• Group 

• Dialog Editor /Composer 



issues 



How to move Content & Results, etc. between 
systems wit h different RECNTT M {inks. 
Program Sharini 



Solution 



Establish Globally Unique Ids for each object that 
must be moved. 
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Health Buddy Database (BDB) 



• Health Buddy Databases (BDBs) are the generic term for XML data transported bet™™ , 
components. BDBs are organized as miniature relational databases, SbSfidh^.^ 
control .nfonnation to interchangeably move between App.icaUon Wer "L itoHan ^ V* 

Previously, survey content had to be written into script language code and compiled BDR, . 
code overhead, reducing communications expense, and allowing the comenno be in ^ ,^ m °? 
even by systems that do D >, support oul VM. A script application can oTn conte^S 1 1 daU ' 
sessjons m varytng ways, depending on patient re q 4ements. For S S S^S^- 
nught be presented content in a larger font. *«™pie, patterns with poor eyesight 

S^t^^STT'- » — - BDB Jail. 

Appliance Requirements 

• Srajidara XML with BDB DTD 

• Support Multiple Tables - Simple RDBMS style. 

• Date/lTme stamps encoded using 32 bit Integers in Unix fonnat - 6 - 

• Support Auto-Increment Integer Type 

• Self-contained for transmission between systems 

« Compactable for efficient transmission between systems 

• Must utilize memory efficiently 

• Appliance code must be small 

• C & Java must be able to work with same format 

• Past storage and retrieval of field values 

tlrfr!' ^ C ' >ema lT1 ^ 0 ~~ Table and Field names - embedded in data 

• BDB and Content Format -versions 

I t0 Up f ad ' C ° de ' CDab,in S M ™ tc °< " * multi-threaded environment 

• Cons.derexphcuOne^To-Many record linking mechanism 

• Arb,trary Indexing for efficient reporting (Temp & Perm) 

Required BDB Appliance Formats ^ 

° Dialog 

• Patientlnfo 

• Patient Program Cube 

• Session Schedule 

• Paw Dialog Session Results 

• Box Control 

• Error Log 

implementation Notes 

t^^'Z^^^ ^ b0tb k° ^ ^ ™^ f0nDflt f0r BOTs wai not be the 

«t EttSSff behiDd " opaquc ^ « BDBs wiU bc frcc * 
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Sized CiUTem " St ° f m fiu,c,i0DS/meU,0ds for ** c indentation. Note: This design has not been 

Init_BDB, Create_BDB, Destroy bdb . 

open_bdb, closejbdb, debug^printjDdb 

» .* 

cfeatejndex, delete_index, get_index_count, select_index: 

add_£ield, get_field_count, get_field^type, get_f ield^name 

gec_record_count, nev^record, modify^record, commit record - 
abort_record . 

* ■ • * * ■ 

first_record, last_jrecord. next_record, prev_record 
get_numeric__data r set_niimeric_data 

• ■ * 

get_string_data_length. get_string_data, gec_substring_data, 
get_string^data_malloc, put__string_data, put_substring_data' 

find_record_numeric, find_record_string 

* ♦ » * ♦ • 

* - h ■ 

Questions 

• Should we have a global DTD and separate DTDs for each object? 
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Cube Object 

Cube Objfcis are responsible for maintaining patient state throughout the life of a program. Metrics are 
stored wtthin the cube and organized by Aspect of Care, Expression, and ^^4^ 
Aspecb of care for a diabetes program might be Foot Care. Eye Care, Blood Glucose MawJ and 

J T^r"™ ihClUde BelK »vior, Sign^ASymptoms. and Knowledge." Additional X£» 
may be added to the system later on. Several different types of data are maintained within Cube obiects: 
System and Program Variables. Refined Output Data, and Meter Readings. Cube objects manifest 
themselves m Afferent ways throughout the system They are kept in part of the application server 
database, travel to appliances wrapped'inside a BDB. and are maintained in summary within each 
appliance. Internal formats for Cube objects are based on a relational database model. 

Requirements 

• Stores metrics by Aspect of Care and expression 

• Standard risk level metrics with values: Unknown. (1-3) Low Risk, (4-6) MedinmTtisk. and (7-9) High 

• I^ heMttriC Wi ' h B session/dialo e «f«ewf M> that we can trace back to the'info that generated the ■■■ 

• Data Types 

• Raw Response Data linked lo metrics 
■• Refined Data from Output Nodes 

• Meier readings 

• Implementation format must be efficient for common reporting requirements 

Implementation Notes 

* 

Issues 
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Dialog Object 

Dialog objects are similar to sub-surveys that interact with patients, take meter readings calculate 
and update each patient's cube state. They are kept as generic templates within a common ™ , 
by libtary. inside an Application Server Database Various parts of A^SlS^ ^ 

appl.ca.,on severs and appbances wrapped up in BDBs. All data generated by Dial OE s are^eJ °T 
Response BDBs and Cube BDBs. A summary version of each patient's cube I £255 Xnthe 

Dialog objects ate composed of Interaction. Evaluation, and Mapping sections. The interaction «*L 
cxpress.ons that evaluate to metric values in me cube. The mapping section links each SSS 

an^C^ "* - "cities 

— ^tenets, with patients and provides output to update cube slate 

- 

Requirements 

• Dialog nodes (Puz2)e Pieces) 

• Question/ Answer (Response) - Standard input methods: Short, Long. Multiple Choice. Prompt 
^ Note: There are twotlavors of question puzzle pieces - Start Question and Follow! ' 
Questioa Only the Start Question is anchored on the work area. P 

• Prompt -Stops and provides text info for the patient 

• Output - Writes output to a patient's cube - composed of a metric calculation section and a 
destmauon map into the patient's cube 

• Decision - Allows branching based on expressions 

• Calculation - Calculates a value using raw response, cube, and mathematical expressions 

• Goto - Jumps to a label piece 

• Label -Provides a target address for goto's 

• Stop -Halls execution of a given dialog 

• Meter- Stops execution and tafces a meter reading 

• Properties . 

• Name - Each dialog is named and is referred by name in various parts of the system 

• Library - Each dialog belongs to a global library 

• Tags - Tags indicate special properties 

• Default Scheduling frequency 

• Default Reporting status ~ 

• Last date/time executed 
LocaJizabon versions within Dialog Object 
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Appliance 

■ * • • * ■ • 

Appliance Summary 

The appliance requires additional functionality in order to support the FlexCube architecture. A to Do I ;<r 
archuccture opens up the appliance for many-lo-many communications and enables multiple ufers onL 
apphance and muJUple ^programs or content sources per user. Content. Results. E-ComJrce S^W 
User and Appbancemfonnation will all ^.transported as BDB XML «™erce ransactions. 

Requirements 

• To Do list architecture 

• a XML / BDB content, results, c-commerce, user and appliance information 
•. New system applications 

Appliance Applications - To Do List Architecture 

Initially appliance code will be written in QCf*,. Later, an enhanced scriptfeg laog»age/VM will enable ■ 
the apphcauons to be wntten in our scripting laneuage. These scripts will be rtpoSble for \Z 
overall box behavor. Responsibilities include Scheduling and handling app BanrcommulaTn? 6 
presenung content, etc. . 4Uons » 

Requirements 

• Box Manager Application 

• Communications Application - Overall responsibility for non-conversational commnnicaboos 

• Connecoon Apphcation -Brings up the physical communications link 

• Login Application - Logs in and establishes a secure connection 

• Mail Exchange Application 

• Session Application 

• Presenter Application 

Box Manager Application 

The Bat | Manager Application waits for one of two events to occur. When it's time to call into the data 
center, the Box Manager calls the Communications Manager and exchanges content, results etc 
Whenever a button is pushed on the appliance, it calls the Login application to initiate sessions and allow 
fnte^y WMc * * 5dBn * * C ° ntCBl availabUir y ™ d check system 

Requirements - 1 

• Handles call-in schedule (Box hardwired with call-back failsafe) 

• Calls Communications Manager 

• Calls User Login Manager 

• Calls Session Script upon user authentication 

• Schedules Results BDB for delivery to application server " 

- « 

User Authentication/ Login Manager 

• User BDB enables/disables user login requirement and style 

• Styles 

• Select User horn List 

• Authenticate via Luggage Lock (Clapp's method) 
Authenticate via Smart Caid 

• Authenticate via PIN 
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Communications Manager 



Requirements 

• Calls Connection Manager 

• Calls Login Manager - 

• Calls Mail Exchange Manager 

• Returns success/failure ' . 

Connection Manager 

S^ 60 ! 00 ^! i< ** m "® be sponsible for dialing into our service provider (ISP orEDSI anrf 
establishing the physical communications link. BDBs will provide a orioritLl kfnf I -T - 
numbers, A fallback 800 number will dial.back to HH^S^S^ 

Requirements 

Brings up the physical communications link 
800 Number for Fallback 

• Prioritized list of local numbers 

Login Manager 

Requirements 

9 Logs into host system 

• Auihenlicates box 

• Establishes secure connection 

• Navigates prior to data exchange 

Mail Exchange Manager 

Requirements 

• Retrieves new content and message BDBs — - ' 

• Uploads new results and message BDBs 

• Uses SMTP &POP3 protocols 

• Will likely use non-standard ports to promote security 

Session Manager 

Requirements 

• Calls FlexCube Presenter Applicaboo to execute content BDBs 

• PnontizedwithRoimd-Robiniesolution. 

• Do not present until rime/date property 
■• Expire after rime/date property 

Required Flag {This must be run before any lower priority content BDBs can execute) 
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FlexCube Presenter Application 

The Presenter Application is responsible for presenting FlexCube content to the patients. 

Requirements 

• Presents content pacJcaged in BOBs to patients 

• Writes raw question responses and evaluations to a BDB 

• Updates Box cube state 

» Supports standard input methods ' 
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Windows GUI Applications 



Dialog Editot? 




Dialog Editor 

The Dialog Editor application is ihe primary tool for content development 

Requirements 
Requirements 

9 Experience Levels 

• Beginner View - Holds author's bands, but doesn't allow full use of system 

• Expert View- Enables all features, expects author to fully understand system 

• Editor Views 

• Graphical Editing view 

• Hierarchy view . 

• List view 

Segregate Dialog Pool into libraries 

• Select Default Dialog Properties 

• Name - Each dialog is named and is referred by name m various parts of the system 

• Library - Each dialog belongs to a global library 

• Tags - Tags indicate special properties 

• Default Scheduling frequency 

• Default Reporting status 
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Program Selector 



Dialog Selection Plotf or m 
-^ a ? Se!e g dtato 9 s to faroartEritog or for arttffipn to program 

^ ' '"^f^r- — - 




^^^S"*" lha ' eDabks Ca,eMansEC,s to bui,d prosraras b > — ■ - * 

Requirements 

• View/Select available dialogs by 

• Library 

• Body System Tag 
e , Name 

• Set Program Properties , - 

• Start and End Dates 

• Inclusion and Exclusion weekdays, dates, aod date ranges 

• Default Reporting Status 
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Program Linker 




jaiiagers 10 set program parameters on a patient by patient basis. 

Requirements 

• ^ *" ° f im0 ° r ° Ut 0f an to «* Pogroms 

5et patient specific program properties 

• Start /Stop dates 

• Include / Exclude specific weekdays 

• Include / Exclude specific dates and dale ranges 

• SeJect and Approve Patient Risk Levels : 
9 ScIect/ Dese]ect patients using standard Windows GUI 

• All 

• Range 

• Individual Select/Deselect 
► Sort List by 

• Name 

• Date of Birth 

• RiskProGIe 
.-• Custom 
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Session Scheduler 

Session scheduler is the application responsible for scheduling and managing content presentations on the 
appliance- It can run as either an automatic engine or as an interactive utility. It is also useful for 
reviewing and editing session data. - 

Initially, Session Scheduler will run msenu-auromatic mode. Care Managers will be able to select a 
patient / program combination and then view the scheduled sessions. Filter control will be provided 

Requirements 

•< • 

Manual and Semi- Automatic. Session generation 

• Ability to view arid edit listed sessions 

• Session status indication - Generated, Deployed, and Completed 

• Session Boundries , 

- ■ - • . 

• Dialogs prioritized within a session" 

• Limit on total dialogs in a session . 

• Dialogs selected based on individual cube state 

• Dialogs selected based on program frequency :" 

» Round-Robin Dialog selection for equivalent dialogs 

• Greeting dialogs with highest priority 

• Exit dialogs with lowest priority 

• Must Execute Flag — This dialog must txecute without aJlowing^patient choice before lower 
priority sessions are presented as to-do items 

• Inclusion./ Exclusion periods for* patients - blackout a vacation period 

• Intelligent Session Deployment 

• Initially, Care Managers will be required to approve sessions 

Future 

•. Support for Population Session creation and scheduling 

• Fully Automatic Session generation 
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Reporter 




Reporter is the pnmary application for reviewing patient results and status as well as paper reports. The 

msss ^" en 31 a r * cUeDL Lato ' rauch of Reponer wm te dupuca,cd us * n8 a fl ^*- 

Requirements 

■ 

• High Level Patient View 

• Clickable Human Body in patient detail view 

• Patient Summary Report 

• Population Summary Report 

• Raw dialog results viewer 

• Report generation summarized by hierarchy ~* 
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Administrator 

Administrator is the application that manages overall system operation aud configuration. • \ 

* * 

Requirements 

• Account Enfry/ Maintenance /Status Changes • 

• Patient Entry/ Maintenance /Status Changes j 

• Copy Programs between Account Entities 

- System Config. Patient Entry, Account Entry 
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Future Additions 

- 

Enhanced Scripting Language - . 

ThesCTipting,^^ 

w,th other system* using the modem or serial port P * '° 

Requirements 

• Sbuctures passed by value into functions 

• Full HAL functionality . ■ 

• Serial & Modem commimications support 

• Date & Time types 

Thin-Client Applications 

ttt*2^*zz* ,o snpply a ^ web ™ * ^ -fc* 

Thin Client Featuies 

V-UMi. access via HTML browser to the system over the internet 

• Global Access to data 

• Eliminates deployment issues 
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Questions 

• In ihc first prototype, should we aim to create sessions on a program basis, patient basis or both? 
(Patient Basis Fust) * 

• Should we build a schema capable of multiple accounts? (YES) 

• Can we really merge raw data into the cube? (Probably, but it would be more efficient to store 
seperatly): 

• Should a patient have a cube for each program? 

Thoughts / Issues 

• We need to support shared pimle-pieces 

• rMaybe have a Global AoG for things like HMO procedure approval screens: Your responses indicate 
physician attention is required, please call Dr.Srnilh if you do not receive a call from your doctor bv 

tomorrow... , * . 

■ ■ 

Need easy way to leverage into thin-client 
Can we ask Mitch to include us in core-engineering discussions 
Wizards . 

GUI hand-holding methods - Help, etc... 
Sharing of Dialogs between accounts 
Moving data between data-centers 
Dialog Interaction Precaution Tags 
Dialogs that refer to outside AoCs 

Development Hardware * 
Investigate DB2 

Input 

• 8/23/99 - AJI new patients get tossed into a special group "New Patients(5)" to make it easier for CMs 
to put into programs: Avoid one big pile of patients where you can't tell wbo is new, etc... 

Albert Schema Questions 

• Many to many on Patient / Account Entity ... 

• How do we move data between DBs? Pra sure this problem has been solved before in various ways. 
But, we need to figure out how. One thing I tbink we can do is integrate account tf into the XML tbat 
we send. Even if it's not part of a given table. This may assist in reassembling the relationships at the 
destination. Another note: Accounts roust be globally unique between all data centers. 

To Purchase ^ 

• DBATool(s) 

• VMWare- 

• Order Oracle? (v 8.03/8.04 issues - CB4 Driver requires a version higher than we have.. .) 



System Features / Requirements 

• Hidden AoCs within Cube 

• Escalations 

■ 

Escalations 

Minimal time and effort required to manage content 
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Glossary 

AppUcalion Server - Computer system including appliance commumcations and thin-client web fronted 
and a database of content, patients, account entities, scheduling, and results. 

Aspect of Care (AoQ - A topic within the Cube Object. Aspects of care for a diabetes program mi E ht be 
Foot Care, Eye Care, Blood Glucose Management, and One-Touch BG Meter. • 
BDB - A micro database object that moves cube content, diaJogs, and raw response information to and 
from ihe appliance. BDBs travel in XML form. 
Database Schema - Stores dialog and program content 

Cube Object - Stores patient state, includes Raw Response Data, Refined Patient Data, and Meter Data. 
Dialog Editor / Composer - An application for creating and maintaining non-personalized dialogs within 
the Dialog Pool in an Application Server. 

Dialog Node -An executable object within a dialog. These correspond to the puzzle- pieces in mnhir-tl ? 
view. Examples include: Question, Output, Goto... "ingrapmcai 
Dialog Object - Interacts with patients and provides output to update cube state 
Dialog Pool - The section of an Application Server that contains content dialog objects 

Ebtpr^ion-AsubtopicwiuiinmeC Expressions are typically Signs & Symptoms. Behavior 

and Knowledge. .» • 

GlobaUy Unique ID - Unique identifiers for patients and other database objects, enabling data portabilitv 
and aggregation. v 3 

library - The dialog pool is partitioned into libraries. An attribute of a dialog. Typical libraries mipbt be 
Diabetes, CHF, or Utilities ' * b 

Localization -The ability of a system to support non-English languages 

Metric - A measurement, most metrics are risk levels or meter reodings. The third axis of the cube 
Personalizer - Maintains patient-specific cube metrics, defining risk levels, etc. 

Program ^lector - Selects dialogs from libraries in and out of content specific.programs, specifies labels 
for scheduling and reporting • . 

Puzzle Pieces - A reference to the graphical objects in the dialog editor. Puzzle pieces include: Start 
Question. Followup Question. Prompt, Output, Decision, Calculation, Goto. Label. Stop, and Meter 
Reporter -Patient results lookup organized into levels from patientlspecific program overview to raw 
results from particular, session, including graphical body system view. 

Schema - A database design, specifying the data stored and relationships between different parts of the 
oataoase • • ■ 

Scrip! - Byte code used to implement appliance applications and evaluate expressions within a dialog - 

Session Application Script - This is a compiled byte-code program that presents content to a patient In 
HexCube. this application will present dialogs and manage cube-state within the appliance as well as 
manage synchronization between the appliance and data center. 

Session Scheduler - Semi-automatic creation and scheduling of patient specific sessions 

SuperNova - An archive and distribution infrastructure for HHN system components. FlexCube is the 

data. SuperNova is the highway. -. 

Tag - An attribute associated with a given dialog / patient or dialog / program. A typical tag might be 
presentation frequency. . 

XML - A text based format for encapsulating and transporting data between systems. The generic format 
used for HHN's data is called a Buddy Database (BDB). Acronym for Extensible Markup Language. 
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1 Vision . 

■ 

mN/of^h 0 ', "? ?TTr a e pBca0ons e,fort is to P™** applications outside the core 
HHN/OLS that extend the delation of the care manager and grow the HHN business ZloZ 
cor^urner-related areas. These areas are in the health care WormaJ £• 
« driven by consumers and not by a hospital or HMO. Applications curlt^ unde 
consideration involve partnerships with: y 

• caregiver.com - Long Distance Care 

. Stadllanders- Care Management of Stadtlanders (medication) customers 

• : Weight Watchers -. Management of people in Weight Watchers programs 

■ * , ■ 

1.1 Vision for Long Distance Care . . 

. The largest group of care managers In this country are family members taking care of aglno 

zzsrtzz s Family rare 9iving has iraMty been a ro, ° °' * ** 5oJ 

l k k y e$e WOmen are " 0W ^■"""f >" workforce. Also, tho mobility 
n I",, f h T 9?nera , ,i0n , haS resulted h ma "y "vino «ar away from their agbg 

parents and other agmg fam.ly members as well. Tlrese two trends have helped create an 
opportunity for technology-enabled, remote care management of elder relatives by babv 
boomer children. 1 y 

1.2 Doeumentatiori 

^T nt * mCMeS m8,eria,S rr0m lhe fo,,owln 9 documents that have been produced 
within HHN; r 

- 

HHNLDGPreIiminaryHLRD.doc 
Informal Caregiver Reqylrements.doc 
Informal Caregiver Requirements.doc 
eg pricing.xJs 

TermSheetforCareguide.doc 
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2 Scope 

The scope of this project is an application built around long distance care. The Health Hero 
Network Long Distance Care Service (HHN/LDC) is envisaged as a value-added service to the 
HHN/GLS that enables care providers such as family members to check on relatives in assisted 
living facilities. The relatives would each have a Health Buddy, and the HHN customers would 
access information via a thin web client. 

HHN/LDC would tie into the HHN/OL'S to communicate wilh the people in assisted living facilities 
Who would answer daily dialogs by using the Health Buddy. The customer would creale 
personalized content for the family member, be informed of certain alert situations, and receive 
reports on the family member's status. 

» > 

The HHN/LDC application is in the concept stage and is currently being discussed with 
Careguide.com. This document represents HHN Software Products' preliminary understanding of 
the application based on input from Steve Brown, HHN marketing, and HHN clinical and provides 
a summary of. high-level requirements and a high-level design for the HHN/LDC application. 

- 

2.1 The Market 

T 

10 million seniors live alone, and 2 million seniors live in assisted living facilities. The 
numbers are growing rapidly because of the aging population. While this drives the care 
management and assisted living businesses, it is also creating huge unmet needs for family 
members. 

♦ 

HHN has lest marketed the concept of . an internet based service that would allow family 
members to monitor parents with a Health Buddy, combining personal messages with canned 
senior wellness dialogues and web-based reports for the family member. The initial 
discussions included about a dozen working women who were in their 40s and 50s, wore 
computer users, and were worried about aging parents. Every one expressed an interest in 
paying out of pocket for such a service "in a heartbeat." HHN has also Introduced the idea to 
three major employers accounting for more than 75,000 employees. Two of these employers 
expressed an interest in offering such a service through their Employee Assistance 
Programs. The price we discussed was $500 lor a one-year subscription. 

More formal market analysis may be possible with Careguide.com as they have 1.3 million 
page views per month from an audience primarily composed of adult children of aging 
parents resulting in 1 7,000 referrals to assisted Irving providers. 

• ■ - * 

2.2 Benefits to customers 

The service can benefit the family member in assisted living: 

• Stay home longer rather than going to assisted living 

• Feel more secure, that someone cares 

• Stay in contact with family member 
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The service can benefit the caregiver: 

• Patient stays home longer saving the cost of an assisted living facility 

• Provides quality assurance of services for patients already in an assisted living facility 

• Reduced stress, improved quality of life for the patient and the care giver 

2.3 Benefits to HHN 

• Huge market opportunity potentially in the hundreds of thousands. . . 

• Higher price possible ■ • 
Consumer privater pay over the web means less contracting issues 

• More control over network for future services such as e-commerce 

• Additional market exposure for the Health Buddy concept 

Putting Health Buddies Into the consumer marketplace would expand the awareness of the 
Heaim Buddy to potential users of other HHN services. For example, people purcSin 2 
HHN/LDC service- might also be diabetics or have other family members who are diabetic 
There are also many upsetting opportunities e.g. HHN/LDC users might be interested in 
heanng about fightweight, warm robes and blankets that can be shipped to a loved one 
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3 User Scenarios 
3.1 Signup/enrollment 

Kate is a 4ayear-old businesswoman and mother of three who lives in San Francisco. Her 
mother is 85 years old and has Just moved into an assisted living facility, as she can no 
longer take care of her home by herself. Mrs. Novitsky takes several medications on a daily 
basis, Is occasionally forgetful, arid generally feels somewhat isolated and lonely. 

Kate has used Careguide.com to lind and select her mother's facility and remembers seeing 
something about a Health Hero service, she goes back to find out more about the service 
After reading the description and seeing how the Health Buddy works she is ready to slqn uo 
for her mother. • 

Kate completes the registration questionnaire providing her contact information as well as 
demographic information about her mother; She closely reviews the Health Hero services 
agreement and acknowledges her acceptance of the agreement She then proceeds to enter 
her credit card information to finalize her request for enrolling her mother in the Health Hero 
program. 

Kate is now on the Health Hero program home page and sees that she can personalize the 
program to meet her mother's needs. She quickly moves through the step by step 
personalization wizard and enrolls her mother in a medication compliance and. wellness 
program. As part of the medication program setup, she is prompted for Information about her 
mother's medications. Kate is asked if she would like to receive a special alert via fax, e- 
mafli or pager if her mother's responses indicate that she is not taking her medications or is in 
need of a refill. Kate has no idea how critical this medication is so she clicks on a link that 
takes her to a detailed description of the medication. There she learns that this medication 13 
very important, so returns to the program set up and selects to receive an alert via e-mail 

She then requests a birthday message for her mom's birthday on Feb 5 th and a special 
"thinking of you" message lor the anniversary of her father's death. Finally, she enters a 
personal greeting message to be delivered to her mother as part of the lirst set of dialogues. 

Kate decides to accept the default set ol reports and has now completed_enrolling her mother 
in the Health Hero program. She call3 her mother to tell her the good news. 

Within moments of completing her enrollment, an e-mail is sent to Kate to welcome her to the 
program and confirm her mother's enrollment. A Health Buddy transaction is also generated 
to FedEx. 

As FedEx ships the Health Buddy, another e-mail is sent to Kate to' let her know that the 
Health Buddy is being delivered to her mother. 
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3 2 Program Delivery 

Mrs. Novilsky has no problem following .ho Health Buddy's setup , nstfUclinn<1 onri - . 
.o recede her « commun^. which sfart3 wi» ,he Z^S^Z^T 

She dutifully responds to the questions for Iho first two da« anrf w l ' . ' 
At time goes by. Kate has established a routine of logging into tho Health h„ 



JJ/2!> 



WO 01/69505 



PCT/US0J/086J4 



4 High-Level Requirements 

This section contains high-level requirements received from marketing. These requirements 
currently comprise features of the envisaged service. . 

♦ 

4.1 Workflow diagram 



Health Hero Services - Informal Caregiver 
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4.2 Health Hero Services Introuuetion/Splash Page 

This web page will contain an introduction to the Health Hero Service and a demonstration of 
a Health Buddy communication. The goal is to get caregivers to sign up for the service. 
Specific features are: . 

* 

• Prompt for user login/password 

• Prompt for New User sign-up 

• Forgotten password assistance 

• Links to Individual program descriptions 

■ • Links to program enrollment checklists (information needed to complete enrollment 
for individual programs) 

4.3 Member Sign Up 

This section will allow the caregiver/purchaser to sign up and activate the HHN/LDC service. 
Specific features are: . 

■ 

Member Registration 

• Caregiver/purchaser information - demographic, contact, login and password setup 

• Health Buddy user information - demographic, contact 

• User can register but not activate/request health buddy 

• Sign up for a Health Buddy e-mail newsletter (generated and distributed by Health 
Hero) 

• Send follow-up confirmation e-mail for new registrants 

• Send notification letter to patient 

■ 

Activation/deactivatJon/upgrades/bundled medical devices 
» Allows caregiver to turn on service 

• Allows caregiver to cancel service 

• Allows caregiver to purchase upgrade services (i.e. BuddyLink, etc) - future 
requirement 

Billing information 

• Credit card information 

Health Buddy Information 

• User entered information - user specific set up information 

• Additional optional patient information - medications, diagnosis, physician etc. 

Health Hero maintained information (or Interlace from FedEx) - Health Buddy serial 
number, ship date (In the future this may be other device information) 
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• Interface to FedEx for Hoalth Buddy. Fulfillment 

• Notification of shipment e-mail to caregiver from FedEx 

User agreement 

• Legal agreement/disclaimer 

• * ■ 

• Caregiver/purchaser acceptance of agreement 

• Patient agreement will be achieved through a dialogue on Health Buddy 

%4 Credit Card Billing 

This component handles the financial transaction between HHN and the purchaser of the 
service. Specific features are: 

Verify credit card 

• ■ * * 

• Interface to service for automatic credit card ver if ication/vaJidation 

Credit card billing transaction 
: • Link to e-commerce server 

r 

4.5 Personalize Program - Wizard for Content Selection and 
Scheduling 

This component provides a step-by-step user interface that walks the caregiver/purchaser 
through the process of setting up and changing programs and dialogues for a Health Buddy 
user. Specific features are: 

■ 

- 

Select and schedule program and dialogues from available library 

» Select from a list of programs and dialogues defined by Health Hero staff using 
existing Composer functionality. Examples of preloaded content are: 

® Nutritional status (e.g. weight, appetite) 

• Medication compliance 

• Regular (e.g. monthly) assessment tools 

• Enter program-specific Health Buddy user information . 

■ 

• Link to resources (ie Drug information, 'health handbook* etc) 
Schedule and create personal messages 

■ - * 

• Short message from informal caregiver to patient 

• Appended to scheduled dialogue 
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• Message scheduled for a specific calendar day or a day of week (i.e. one time only or 
repeating) or to be delivered in the next communication 

Schedule and create sponsor messages/dialogues 

• Sponsor may be Caregulde.com, Weight Watchers, or other third party 

• Caregiver option (on behalf of patient) to receive or not receive sponsor messages 

• Dialogues created by Health Hero using existing composer functionality 

• Dialogues or messages assigned and scheduled by Health Hero 

• Dialogues or messages appended to consumer-scheduled dialogues/messages 
Specify variables 



4.6 Personalize Reporting and [Alerting Wizard 

This component provides a step-by-step user interface that walks the caregrver/purchaser 
through the process of setting up and choosing reports and alerts. Specific features are: 

Specify alerts 

- 

• Select alerts from predefined list. Examples might include: 

• Non-response for specifiable (e.g. 3) number of days 

• Significant (specifiable e.g. 5 lbs) change In weight 

• Request from family member for a phone call 

• Medication non-compliance (specifiable e.g. more than 3 missed doses per 
week) 

• Specify when and how to receive alerts 

» Displayed on Health Hero Services Home Page (within Careguide.com) 

• E-mail 

Specify reports 

• Select from predefined fist of reports. Examples might include: 

• Nutritional status and weight tracking report 

• Medication compliance report 

• Reports from assessment tools 

• Option to preview a sample ol report 

• Specify report recipients 

• Specify report delivery mode - fax, e-mail, display on-line 
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» Specify report frequency - dairy, weekly, monlhly, quarterly 



4.7 Viewing Status and Reports 

The careglver/purchaser will have a personalized Hearth Hero Services Home Page. This will 
allow the purchaser to view: 

• Alert messages • 

• Program summary 

• Sponsor or Health Hero messages to caregrver/purchaser 
» Links to careguide (or other sponsor) web pages/content . 

• Caregiver : selected reports with fax/e-mail/print/view on-line options 

• To physician 

• Other care manager 

• Others 



4,8 Help 

Help lor the customer will include: 

• On-line FAQ accessible via Health Hero services home page 

• On-line documentation 



4.9 Customer Service 

On-line e-mail 

Health Hero support staff respond within 24 hours 

Telephone 

• Health Hero staff for "use of service questions* 

• Call center partner for clinical/health related questions 
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The Long Distance Care program could include: 
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Program Content 



Personalized Content 



Nutritional Status (weight, 
appetite, eta) i . 

Wellness Rating Scale 

Medication Compliance 

Monthly Assessment Tool r 

• QOafity of Life Tool 

• ADL 

• I ADL 

» Salety 

• Depression 

• Mini Menial Status Exam 
Personaj Hygiene 

Skin Care 

Nail Care (Podiatry) 

Sleep 

Safety 

Nutritional Needs 

Primary, Secondary and 
Tertiary Care 

T 

Loss and Coping 
Social Support 
Urinary Incontinence 
Bowel Function ■ 
Activity 

Financial Status 
Barriers to Compliance 
Tip of the Day 
Trivia 

Motivational 



Personal Messaging 
Scheduled (i.ej Birthday) 
Reminder Service 
Personal Variables 
Personal Goals 



Reports 



Alerts 

• Non Responders 

• Significant Change in 
. .Weight 

• Significant Change in 
Wellness Rating 

• ^Medication Non 
Compliance 

» Request for a Call 

» individually Selected 
Key Indicators 

■ - 

Monthly Reports 

Individually Selected 
Variables 

Statement of 
Nutritional Static 

Report of Medication 
Compliance 

Monthly Assessment 
Tool Findings 

* Acknowledgement and 
Affirmation of Status 
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Up-Selling Opportunities 

Fmancia! Planning 
Books 

Long Term Care Facilities 
Pharmacies 

Webvan.com 
Support Groups 
Medical Support 
Durable Medical Equipment 



Insurance 

Long Term Care Planning 
Safety Products 
Drug Stores 
Card Game Sites 
Travel 

Online Shopping 
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5 High-Level Design 



The currently envisaged design is a simple thin client web interface for the fcmih; u u 

purchaser/caregh/er. Content will be created bv hhm ™ th,T ^ ump05er ,s not squired by the* 
Care Doctor and Care Administrator Is not required. required. much , of the 

ma,n .dea is to keep things simple for the subscriber. scheduhng interface. The 

The HHN/OLS v2.o architecture currently under discussion includes minr^n , 
HHN/LDC. As such, work on HHN/LDC and HHN/OLS v2.0 need to be synchronJeT 

5.1 User Interface 

The user interface is determined by the actions that the subscriber needs to n Drf ~ -ru 
^-"onsoffcefamiVmemb^^ Th ° 

S^»/h 5 /„ io t/,e LDC program. These screens allow entry of current users to secure 




Login dialog 



form 




Includes: 



usemame/password input boxes 

new user link - loads form to colloct Information on 
new user 

forgot password link - loads form wtlh Inslructlons for 
calling to get password ~ - 

program descriptions link -- loads form with 
descriptions of available programs 

program enrollment »nk - loads form to capture 
information necessary for enrollment In Individual 
programs 
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Slgmng up Jo the LDC program^ Those screens should include capture of dala re the 
career and .ho patient that enable shipping of a Hea.th Buddy to the patient The screens 
should accept the family member's credit card as payment for the program The credit card 
billing infrastructure will require a link into an e-commerce server. • 



WPtlCATIOM* 




Caregiver/ 
purchaser 
Information 



Health Buddy 
user 

Information 



Health Buddy 
User 

Agreement 



Activation 



User 
Agreement 



Bitting 



Form 



Fprm 



Heafth 
BudoV 
dialogue. 



Confirmation e-mail Is sent to 
new ca r egi vgt3. 



NoOficatloh letter Is sent to 
patient 



Caregiver acceptance of 
agreement required to move 
on. 



FedEx EDI Interaction 
completed and e-mailed from 
- edEx to caregiver generated. 



The caregivers demographic, contact, login and 
password setup Information Is captured. Caregivers 
can optionally subscribe lo newsletter 



The Health Buddy users demographic ond contact 
Information is captured. Optional information e.g. pt 
medications, physicia n, Is captured. 

Legal Bgreemenl obtained via Health Buddy dialogue. 



tows caregiver to turn on, cance l or upgrade service. 
Legal agreement, disclaimer Is loaded. 



Credit card information captured. Verification and 
validation achieved via Interface to service, 
"ransectlon logged via eCommerce server. 

Captures information necessory for FedEx EDI 
ransactlona 



Choosing LDC preloaded program, creating personalized messages and scheduling 
preloaded and personalized dialogues. These screens should allow the family member to: 

• Select an LDC program and dialogues based on contenl that are available in the 
(content) database. 

• Create a message (prompt) that can be scheduled to play, on the Health Buddy on a 
specific date. These personalized messages can be stored using the patient variables 

• structure. 

■ 

• Schedule selected content. This should look tike a calendar that is~populated based on 
what LDC preloaded program Is chosen and what personalized messages are created. 
The calendar should be editable. The scheduler/calendar may need to be an applet in 
order to offer the required functionality. Scheduling using the current architecture is a 
major Issue. Please see the section describing some of the issues! 



APPLICATION 








LDC Program 

• 


Form 

4 p 




Select LDC piogram(s) e.g. 

• Nutritional status 

Medlcetlon compliance 
Regular assessment tools 



t 
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AP>LiCATOfr 

cow^r^/* 




:r.' V^V-* <• ." - C '^xi-i r« ^ : : 




LDC Messages 


fomt. 




Create messages for schetfufing with LDC program 
dialogues . ■ 


Schedule 
Calendar 


Form 


» * 


Schedule LDC program content wlrh appended 
personalized messages for delivery via Health Buddy 
Can be edited r ' 


HFtesources 


Form 




Links to avaDabte Health Care Resources Lei Drue 
nlormatlon, "health handbook', etc. 


jsponsor 
yMessages 


"orm 


m 


Caregiver can elect to nothavo sponsor messages 
show up to patient '(seo sponsor below) 


^Variables 


Form. 




ADows caregiver to enter pt-speciflc values Instead of 1 
defaults set by HHN. I 



Choosmg, scheduling, and viewing reports. These screens will provide a. web interface 
tor a report menu where previously created reports can be viewed, reports can be run and 
reports can be scheduled lo run al defined limes. The reporting win require a report server 
on the back end as an additional piece of architecture. 



COMT F NT^^*^ 


mm 




wmmimmmmmmm 


Alert Selocl 


Form 


• 


Select Alerts From pre-defined list Specify how lo i 
receive alerts: e-mefl, web. | 


Report Solecl 


Form 




Select Reports from pro-defined list Option to preview 
reports. J 


Report Delivery 


Form 




Specify report recipients, delivery moda and l( 
frequency. B 


[Alert and 
Report Viewing 


Form 

* 


» 


Viewing options include 

• Alerts 

• . Program summary 

• ' Sponsor or Health Hero messages lo caregiver 
» Links to careguide {or other sponsor) web 

pog^s/content 

• Caregiver-selected reports with faxfe- 
moiVprint/'view on-line options 



'Creatlng/scheduirng sponsor messages/dialogues. These screens should allow tor 
creation and scheduling of sponsor messages. This may be a screen in a separate wizard 
that can be run by the sponsor (i.e. Careguide.com or other third party), or created by Health 
Hero using existing Composer functionality. 



APBLlCA^lOMtj 
CQrvfTEMHf^. 


v r ZT? \-~ 






LDC Program 


Form 




Select LDC program^) e.g. 

• - . Nutritional status 

Medication compliance 
Regular assessment lools" 


LDC Messages 


Form 




Create sponsor messages for scheduling with LDC 
program dialogues 

- ' ". 1 
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APPLICATION" 

.» - — • _ . - » "* 
. . . ♦ .>*•*-*-.- - 


control; 


yAtipATl6wRUt£^^y^ 


6ESCSr^lONi^w^*^^ 


Schedula 
Calendar 


Form 




Schedula LDC program content with appended, 
sponsor messages for delivery via Health Buddy Can 
boGdlled. 



The design of the user interface will be wizard-like, stepping the caregiver through the above 
actions. The interlace will be web based so that no Installation will be required on the client 
machines. 

The user interface will be entirely new. Some of the current screens could be used as 
riddels, but most of the interaction that the subscriber will have with the system will be at a 
simpler level than with the current care managers. The user interface win be simple and easy 
for a subscriber to walk through and find what they need. 

5.2 Server-side changes: Database and Middleware 

» 

Based on the requirements for the interface, most olthe server-side changes will be in 
scheduling flexibility and the addition of servers/middleware to handle reporting, alerts, and e- 
commerce. 

The key database and middleware actions in the HHN/LDC service are: 

• .Construction ol surveys from preloaded and personalized dialogues; ready for 
download to Health Buddy with specific dialogues or on specific dates. 

* * r 

• Handling situation where survey is not answered, Le. queuing of surveys while 
allowing for personalized dialogues to run In the box on a given day. 

• Modifying surveys that have been constructed and are scheduled, to add further 
personalized dialogues. 

» Scheduling constructed surveys to run on Health Buddy. 

• Scheduling reports 

» Running reports and returning results to files that are linked to family member web 
pages. 

« Including graphs in reports. 

• Handling ol role-based security, archiving and distribution of reports. 
» Handling alerts.. 

This database and middleware functionality requires additional middleware to be written for 
database communication and communication with an additional report server, graphics 
server and web server. Middleware changes need to be made to allow extra flexibility in 
scheduling. (Please see scheduling section later). 

When reporting from the server, the middleware components interact with the database, the 
graphics server, the web server, the report server, and the report writer. There are two- 
distinct sets of middleware: those interacting with the web server and those interacting with 
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Iho report server to create reports. The components used by the web server assist in 
creating dynamic web pages for display to the user. The components used by the report 
server handle the interactions between the graphics server, the database, and the report 
writer to bring all the pieces together into a completed report. 

The middleware components interact with the report writer to construct the reports from 
database data and from graphical and textual output produced by the graphics server. Tho 
middleware controls the creation of ad-hoc reports with help from the report writer's functions. 
Data may be sent from the middleware or from the database to the graphics server. The 
middleware connects to the various databases that are supported in the application. 

Changes to the current database should be fairly limited There will be multiple additions 
however, since the database will have to^tore additional information, such as credit card 
data and alert information. A more in-depth review of the requirements will be needed in 
order to list aB of the database additions and changes. 

The current middleware can be used with additions and modifications to handle the additional 
data and the additional server-side components that are required for reporting and e- 
commerce. 

* * ♦ 

5.3 Application Content 

. 4 

■ . . 

In order lor this application to be relevant to a wide patient population, a significant quantity of 
nigh-quality content needs to be developed and integrated into the application. Content areas 
may include: 

• Personal hygiene, skin care, nail care, sleep, safety, social support, urinary 
incontinence, bowel function, activity, financial status, barriers. . 

• Nutritional status 

• Medication compliance 

Other key tasks in the content area are: 

o Content needs to be arranged to be readily scheduled into marketable programs e.g. 
monthly, quarterly etc. 

o Content needs to be tagged to enable reporting ol results. -= 

The pre-defined application content will be created by HHN or the service provider using tho 
Care Composer. The content will be stored, created, and reviewed using the Care Composer. 
The subscribers might be able to review the content but they will not be able to modily the 
pre-defined content. Personalized messages can be added to tho pre-defined content. 



20/2!) 



WO 01/69505 , PCT/US0J/036J4 

5.4 Survey definition and scheduling 

The current dialogue scheduling architecture, has two signincant problems in the context of 
HHN/LDC and other applications (e.g. HHN/DMS -Diabetes). 

.. • There is no way to merge content at schedule time 

• Only one survey per day can bo sent to the Health Buddy 

For the HHN/DMS system, we add personalized questions (goals) to pre-loaded surveys 
(education subtopics) by specifying goals as program metrics. Wo specify one metric that 
sets an upper limit on the number of goals allowed and Individual metrics for each possible 
goal. Questions based on these metrics can then be added to each pre-loaded survey 
(programmatically). These questions act as placeholders for goaf questions that may be 
asked at some point in time. 

The architecture described above will work for the HHN/LDC application only if we ensure 
that some pre-loaded content Is sent to the Health Buddy each day. Even then, if questions 
are not answered on a given day, surveys scheduled for the next day will not be sent on that 
day. the current architecture thus does not ensure that personalized content scheduled for a - 
specific day will actually run. The best we can do in the current architecture Is to allow 
personalized messages to be appended to dialogues that are part of the program, and for the 
program dialogue and message appendix to be run in sequence. However there would be ho 
guarantee that a personalized message would appear on a particular day of the year. 

Going forward, a more flexible architecture is desired Features and requirements should 
include: 

• Ability to combine surveys for scheduling on a given day. 

» Ability to schedule surveys like appointments e:g. weekly, monthly etc. via a 
calendar. 

♦ * 

The scheduling of personalized content is one area where a lot of work will need to be done 
to give the flexibility requested in the requirements. There are some workarounds as 
described above, but the flexibility desired rn the requirements would not be completely 
attainable Willi the current scheduling and addition of content mechanisms. Note that all 
additional work on content scheduling would need to be done by, or in conjunction with, the 
HHN Mountain View Engineering team. 
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5.5 Reporting 

The reporting component is a crucial part of the HHN/LDC. Subscribers need to easilv 

;^JSSfflKST" - —5 

The simplest, cleanest approach to reporting is to set up a new report server (with report 
miter). staUstk^graphtes server, and a web server. The rep Si server wTrZe 
middleware for connectivity to the transactional database at EDS and lor connectivity with the 
report writer, statistics/graphics server, and the web server. . 

Given the current HHN internal processes it would be most efficient for this project (and for 
the *0 core offering) to set up separate boxes for a report server (with report writer) 

ESXS T" !* Se,Ver ' TheSe b ° Xe9 W0U,d b9 sel "P ™« managed 
Hitemally at HHN and communicate with the EDS data center only for pulling data from the 
transactional database as required. .s <w «unnra 

The HHN/OLS v2.0 core reporting framework currently under discussion Is highly consistent 
with the reporting requirements for HHN/LDC. As such, work on HHN/LDC and HHN/OLS 
V2.0 needs to be synchronized. In particular, requirements and design for the reoortha 
component of HHN/OLS V2.0 need to be defined before- any work on the reDOrtino 
component of HHN/LDC is done. HHN Sollware Products has a Preliminary High-Lew* 
Reqwemenis and Design document for HHN/OLS v20 Batch Reporting. That document is 
currently in circulation within HHN Engineering. . 

Since Ihe reports will consist of text and graphs, there needs to be some way to combine 
these items and also produce Ihe graphs without a user interface interaction; For this and 
other reasons, it is suggested that the reports be produced in PDF. PDF format is 
widespread and makes it easier to control layout than with HTML and other formats. With 
PDF, the report will be read-only and accessible from a variety ol systems: 

The following section describes a reporting architecture that provides significant scalability 
and workllow efficiencies. The architecture will allow subscribers to automate report 
generation and distribution. The following sections are consistent with the Preliminary Hlgh- 
Level Requirements and Design document lor HHN/OLS v2.0 Batch Reporting and Ihe 
reader is referred to thai document for additional detail. 

5.5.1 Reporting Architecture 

The proposed reporting architecture is based around a thin client web-browser user 
interface. The user interface displays a lisl of reports and enables reports to be 
scheduled or interactively run: Report results are automatically archived and managed In 
a hive, are available lor viewing via role-basBd security, and can be automatically sent to 
other people as appropriate. . . 

The server-side architecture is asynchronous whereby a user connects, requests a 
report, and can either wait lor the report or disconnect and get the report later. The 
asynchronous design provides more scalability since reports can be queued and 
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* 

processed by the report server. The asynchronous architecture also handles problems 

• that could occur with someone on a bad connection; if the connection gets dropped, the 
repori will bo waiting when they get reconnected. The report server atlows for the 
scheduling of reports, if those reports are run on a consistent basis. 

The central points of action in the architecture are the middleware components, which 
act as traffic cops handling interactions between the other components The middleware 
components use the report writer to create reports that are sent back to a web page. The 
middleware handles getting data and analyses from the statistical/graphical engine and 
publishing the data or sending the output to the report writer. 

■ ■ • ■ 

The report writer allows for creation of report templates that can be easily modified at 
.^runtime to handle the ad-hoc nature of report options. The report writer handles the 
creation of the reports and the export of reports in various file formats. On the server- 
side, the report server uses the middleware and the report writer to process reports that 
are returned to the web server. When running reports on the server, the web server 
handles an user Interaction with the server- 

■ 

* ■ 

A repori server is needed to manage the security, scheduling, and distribution of reports. 
There are available products that suit the needs of HHN applications without HHN having 
to build a report server. Currently, Report2Web has been reviewed. Others currently 
being reviewed are Brio.Report, Actuate, and WebFocus. The main purpose of the report 
server is to manage reports so that users can request reports, retrieve them later, and 
rerun reports using saved setlinjgs. On the web server, a user's security level determines 
the reports a user can run. The report server allows a user access to only the reports 
that the user ran or ones in "public" folders. The report server processes reports 
requested by users via the web server. The parameters and other report information are 
read Irom the web server and used to create the desired report with the correct options. 
The report server interacts with the middleware components to create reports using the 
report writer components and output from the statistical/graphical engine. 

* 

The statistics/graphics server manages sessions in which specillc graphical analyses 
are run depending on the required reports and personal data. Currently, StatServer from 
MathSof t has been evaluated. This readily handles the data analysis sections of reports, 
creating graphs or data sets for display in reports. The database system is currently an . 
Oracle database at EDS. _ . 

When the user selects a report, chooses options, and submits the report, the middleware 
handles the interaction with the statistics/graphics server. For example, an instance of 
the statistics/graphics engine is created via its Open method, and a new analysis object 
is created. Then, arguments and data associated with the analytic used are passed to 
the analysis. Alter this, the Run method for this analysis object is called. The results are 
returned to a tile, which contains the information relevant to the report. The image and/or 
summary statistics is then embedded into the report by the middleware. 
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5.6 E-Commerce and Fulfillment 

Additional server-side processing will be required to validate the credit card for the bflllno 
processes. The smer willneed to connect to a credit validation service to be able to 
process the order on-line. This will require extra middleware and/or an E-Commerce server 
to handle all of this processing. 

A summary of E-commerce servers is provided as. an appendix. For the HHN/LDP 
appllcahon. at first blush, we think the IBM Net.Commerce product would work weD Thk 
would need to be investigated: further in association with current and anticipated future 
commerce requrrements. y B 

* * * 

Faifillment will involve interaction with the FedEx system currently in development As wa 
understand it. an API to the FedEx EDI factory will be available and we will be"abie 1o 
programmatically cbnl»gure> transactions and exchange transaction components. 

The FedEx EDI interaction may look Oke> the following: 



Consumer 
caf ggulrJe Ul 
(program 
activation) 












CCard 






Voi location 






and 






BDIng 





MHN 
E -commerce 
ser»or 
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Database 



PO (850) 
FA (997) 




POAck (855) 
FA (997) 



PO (850) 
FA (997) 






FodE* 






Shipping and 






Dbtlbuiton 






Center 





Shipping No Weal Ion (856) 




The HHN/LDC application development will need to slay close to developments in the 
FedEx fulfillment system and to integrate accordingly. 
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5.7 Overall Design Issues 

it is. envisaged that HHN/LDC would address the requirements described above through a 
new thin client web user interface that facilitates communication with- the Health Buddy via 
the HHN/OLS. The selected content topics would be linked to dialogues in the Data Center. 
These would then be run remotely over the Health Buddy appliance. This thin client user 
interface would also communicate with a report server, graphics server, and web server that 
would pull data from the HHN/OLS Data Center, run reports, and link reports to the family 
member's web page. 

* 

Many of the architectural issues discussed herein are currently being discussed by the HHN 
Architecture team. Some of these issues, while specific to the LDC project, apply more 
generally to a more flexible next generation HHN/OLS system, in particular, the architecture 
described above would provide a flexible, asynchronous, server-side reporting system for the 
core system. The scalability and the asynchronous nature of the proposed reporting 
architecture will provide a fast user experience while managing demands on server 
resources. The major areas that need improvement for this project are more dynamic 
scheduling of content and reporting/alerting of users. 
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6 Going Forward 

- 

6,1 Key Business Analysis Considerations 

♦ ♦ 

Caregulde.com 

■•■-.* - - ■ 

The case for developing this product lies in the potential business relationship with 
Careguide.com. .Specifically, given that this is. a serious opportunity, an HHN team needs to 
meet with Caregulde.com in order to gain an understanding of: 

Careguldexom's current product and product development milestones 
Key goals and requirements of this application from Careguide.conVs perspective 
How and where the project will provide profits to HHN and to Careguide.com 
Risks for Careguide.com and HHN ... 

• * * 

Who will own and develop ancillary business opportunities 



6.2 Software Lifecycle Development 

HHN Software Products has the following phased software lifecycle development process: 

1 . High level requirements and design 

2. Detailed design 

3. Development stage 1 

4. Deployment as beta 

5. Development stage 2 

6. Commercial deployment 

Typically phase 1 takes one to two months, depending oh availability of solid requirements 
and phase 2 takes approximately two months. Milestones and schedules for stages beyond 
this can not be determined until the detailed design is in place. 

The development of the HHN/LDC system will have to closely follow the other changes being 
made in the core HHN system. Many of the major changes required to make the HHN/LDC 
successful are in discussion as changes to the core system. The HHN/LDC requirements win 
be helpful in defining changes that need to be made in the core system, changes that will 
assist in the development of the HHN/LDC service going forward. 
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6.3 Next Steps 

Discussions with carGguicte.com neod to bo contained to developing an understanding of the 
potennal relat.onsh.p, then current product and product development milestones and kev 
goals and requirements of this application from caregulde.com's perspective. ' 

» 

Conditional on the business case and interest, the following internal resources and activities 
are required: 

1. HHN Software Products Involvement. HHN Software Products to meet with 
careguide.com in order to begin a software business analysis and software 
requirements/design process. Some Issues involved In this process are addressed 
, above. Th.s work would result in a Detailed Design document for the software build. 

Z HHN Marketing Involvement. HHN Marketing to develop a concept document and 
a marketing requirements document for this project 

3. HHN Clinical Involvement. HHN Clinical Department to contribute to the concent 
document, the MRD, and the Detailed Design document ' 

* * » * 

4. HHN Engineering Involvement HHN Engineering to be involved in any changes to 
the current middleware and Care applet functionality as described above. 

* - - ■ 

5. HHN QA Involvement HHN OA to be Involved in testing and deploying any system 
bu.lt, and estimates of their time would need to be Included in any project plaa 

6.. HHN Supply Chain Involvement. HHN Supply Chain to be involved in setting up 
trie eCommerce server and the lulfillment and billing processes. 
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Appendix: E-Commerce Servers 

• * 

E-Commerce servers come in four broad classes: 



Web Storefronts are shrink-wrapped catalog products that enable ,imn.„ „ 
a web browser. They typtcally provide s.ore creation wiSds salK , " W 
payment system. Additional functions include catalog S£ search ** * 

carts, and order tracking. No gateways or APIs S^KSE? - ^ 
support, or rnventory systems are usually provided. Links aTe tSSt 5?* 
screen-scraping, and flat data. Web storefronts typica»y un^ m83sa 9 ,n 9' 
platforms and are priced in the range $100oTSoOo vOl S<mB UN,X 
Net.Commerce (vmvM.irmconVsof^^ ,BM 

.^^^ ° Pe " ^ 

^^^^ ^ 
product sales ^ 2^?^" *^ ^ 
scraping links to inventory and accounBng sSs ° r SC,een 

on NT and UN.X platforms and are SS, ^^0^ 
include CommerceOne fwww.commP^n^ mn.i ClL s J° ' °°- Vend °' S 
Ariba (^~!b^^ (^laruscgrp^ and 

2^J"!^3^ and p,o r mmin9 ,6 °' 3 ^ enabi8 — ^ 

y y>c uuira to Junctfona servers wth oa»owav«t ™ adi * L . 

SXo t So^ t 7 °" 'JL'S UN ' X P ' aK0m ' 3 and a ' e P*" In to range 

Server Grade a^P / ^^awsl, Microsoft Srte 

server, uracle, and Procurenet ( www.procurenel cnmf ! ■ 

stoSriti r 6 ?,^ " 0n shrink ' wra PP^. customized solutions incorporating 

^sZZX^'^ T" ' 00lS ^ ^ ob i—-n.ed APIs and' 
LrtTiMt „ P 9 ° y EC 3yS,e,ns - En,ef P'ise servers typically run on NT 
P,aM0,mS and are P riced h ■» range $50,000 to $500700^^ ^1 
Connect (w^connec^^ and Broadyfeion fwww.broadvLnn S 
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